I have to admit that the Factorio development is slowed down these days, but it is not stopped because it just can't stop. Or is it because we can't stop? I guess that we have come too far to give up who we are.
Hello, We know you love to blow things up, and the Space Age expansion will be bringing ever more advanced and powerful ways of bearing arms against your enemies.
New test servers We recently bought and assembled some high-end PCs, with the hope to gauge performance, speed up running tests, and potentially consolidate the number of servers we are maintaining internally. The two lucky CPUs were a i9-9980XE 18-core and a Ryzen 3900X 12-core. We are using the time to complete our test suite in 'heavy mode' as a benchmark. Heavy mode basically saves and reloads the game each tick, and compares a CRC of the map from before and after. It is super slow to run, but the heavy test is critical to help find any possible determinism issues. There is some more info on 'heavy mode' in FFF-63. As a baseline, the 'standard' CPU in the office for developers is the i9-7900x 10-core, which runs heavy tests in about 530 seconds. In real time this is 8 minutes and 50 seconds, a long time for a team member to sit around for results before they can push. We can do better! As you would expect, the new 18-core was blazing fast, with a test time of about 400 seconds, shaving off over 2 minutes. However the Ryzen was a different story, with a test time of about 600 seconds. This goes against what we predicted, where more cores and higher frequency mean lower test times. The initial results from the 12-core Ryzen were worse than from the 10-core Intel; not a good start. So I did some digging and some research, and the answer I arrived at was RAM. When we ordered the parts, not much thought was given to the selection of RAM, just some standard 16GB 2666MHz sticks to fill all the slots. Luckily, I looked on a local Czech website, and they had some stock of the brand new G.SKILL 3600MHz Trident RGB Neo, a high performance RAM stick made exactly to suit our new Ryzen CPU. After installing the new RAM, we had a test result that better matched our expectations: 450 seconds. We knew beforehand that Ryzen liked fast RAM, but we didn't realize how significant of a difference it could make. So now we have set up both these new machines to run tests automatically after each commit, and we are very happy with the result. The new i9-9980XE can compile and run heavy tests faster than our old i7-4790K can compile and run just normal tests. Having it run automatically also frees up individual developers from the responsibility of running heavy tests locally, so they can just push as normal and continue working.
Hello, it has been extremely cold these last weeks. It's one of those weeks when we can't think of anything to write about. So we will try to write some small parts.
Not mentioning it would be weird I really think everybody has heard all about this and nothing else over the last few weeks, but yes, the Coronavirus. For now, with Factorio, everything seems okay. We are all working from home, the team is still going, and so far we are following our plan quite well. We released the Character GUI and Statistics GUI last week, and some improvements such as new water splashes and leaf animations this week. Things are still moving along. However it is still early days, we haven't really had any experience having the whole team work remotely, so there may be some challenges we need to tackle as time goes on. At the moment we don't know whether this will affect our 1.0 release date, I guess it will one way or the other, but for now we aren't announcing any changes.
Hello, the 0.14 stabilization is still ongoing, we are in the final stretch now and hope our latest release might be declared stable soon, along with a marketing push on steam. Until then here is some news about ongoing developments this week:
Hello, we have a nice anniversary of the friday facts today, as we have one friday facts for every bit in the 64bit architecture address size. I believe this is the best time to show some of the 64 pixels per tile graphics experiments as well.
The programmable speaker There has always been some talk around the office about a music box that can be used to make simple sounds, you could even connect it to the circuit network and make simple songs. I put it on my long list of circuit network ideas, and in the past few week it has been coming to life. So today I'll be talking about an exciting new entity coming in 0.15: the Programmable Speaker. It was designed to do two main things: Show configurable GUI alerts and play audio alerts based on circuit conditions. Play audio samples as controlled by the circuit network in a way that simple songs can be created. The entity graphics are placeholder programmer graphics. Let's start with the useful part, it's pretty straightforward. You set your circuit condition, set the sound you want it to make, set whether the sound should be heard in that part of the factory or across the entire map and add an optional GUI alert message. When the circuit condition is true, the speaker will play the selected sound and show the optional GUI alert. You can let the sound play continuously or use simple combinator logic to make the sound at custom intervals. And now that fun part. We knew we wanted the Programmable Speaker to be able to make simple songs. Crazy ideas started to pour in, and it was quickly becoming a full-blown music production DAW with custom synthesizers and control over everything. But this has to be easily controlled by the circuit network without having to build real-time computers with combinators. So in the end I made the Programmable Speaker work as a step sequencer. If you send a circuit network signal pulse, an audio sample will start playing, otherwise nothing will happen. There is no control over the sample length or any special effects, but this means it is quite easy to control it using the circuit network. Enough talk. Here is a demo of a song made using the samples already included. Everything you hear is created inside Factorio. I will leave it to you to analyze the video and figure out how the song is generated. Modders can easily add more audio samples to the entity, including custom alerts. I imagine there will be a voice pack mod that could be programmed using combinators to speak things like "Crude oil is low". I'm sure the Programmable Speaker will be part of some very interesting posts on the Factorio Reddit. There are some other circuit network improvements coming to 0.15, but I will talk more about them in some other FFF. The map download struggle (Technical) For as long as I can remember, our multiplayer map downloader had (among other problems) the problem that it would get stuck at 100%. It was an extremely rare problem some random person would report. We would keep ignoring the bug throwing it in "Pending" or "Duplicates" or "1/0 Magic", but after a few months some other person would report it again. I seem to have a habit of obsessing over these rare "unfixable" bugs (audio mixer crashing, vsync performance issues, non-pixel-perfect sprite drawing), so I started looking into this map downloader issue. First I was looking at the map downloader code itself, thinking surely there is something wrong there. This was a long process because I had no way of reproducing the issue, so it usually involved going back and forth with a person who was experiencing the issue. I would create an executable that would create detailed logs, that person would run the game using that, I would investigate the logs and see that our map downloader works correctly. The I would add more logging and so on. By the time I would reach some kind of conclusion that person would stop answering and probably stop playing Factorio. But near the end thanks to some helpful players, I was able to see what was happening. Looking at the wireshark capture for both the client and the server, it seems that a packet with a specific content or a specific checksum always gets filtered. Some cheeky firewall from the computer, router or ISP is looking inside the packet data and blocking the packets it does not like. No matter how many times I resend that packet, it never gets through, while all the other hundreds of thousands of game and map packets have no problem getting through. Correct me if I'm wrong, but something like this should not be happening. You can read all the details and see the packet data last posts of the forum topic. The issue seems to be resolved if I add one byte of random data to the packet, but I would like to know why is this happening in the first place. If you know what is happening or you know someone that might, please don't hesitate to enlighten us :) This shows how hard it is to make software that "just works" for everyone. There will always be that 0.1% of people who end up having problems that no one could have ever foreseen. Big thanks to admalledd, dadymax, Rippie and the other forum members who helped or are still helping me investigate this odd issue. In other good news, while Rseding91 was also looking at the map download code trying to investigate this problem, he found we had some slow code doing hard drive seeking, slowing down map uploads. He improved it and you should see better map transfer speeds on LAN and high speed connections. As usual, let us know what you think at the forums.
Good day to all, it is hot here. Really hot. We have loosened our "dressing policy" to "no T-shirt is fine". Both of our fans are running full speed and the fridge is stacked with ice cube plates. People come and go all the time - it is the mids of vacation period after all. Half empty (or half full) office has become a standard these days. Still the work goes on and there is progress.
